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Abrechnungs- und Kundenverwaltungssystem 
Beschreibung 

Die vorliegende Erfindung betrifft ein Abrechnungs- und Kundenverwaltungssy- 
stem, insbesondere fur Kommunikationsdienste, nach dem Oberbegriff des An- 
spruchs 1 . 

Abrechnungs- und Kundenverwaltungssysteme werden in alien Firmen eingesetzt, 
die Giiter oder Dienstleistungen anbieten, bei denen die Hohe des Verbrauchs der 
Guter bzw. die Lange der Nutzung der Dienstleistungen die wesentlichen Kriterien 
fur die Hohe des zu entrichtenden Preises durch den Endkonsumenten darstellen. 
Diese Firmen besitzen zudem meist eine sehr groRe Anzahl an Kunden (vgl. 
Strom-, Gas- und Wasserversorgung, Telekommunikation), was einen enormen 
Verwaltungsaufwand nach sich zieht. Abrechnungs- und Kundenverwaltungssy- 
steme ermoglichen solchen Firmen zumeist eine einfache Verwaltung der enormen 
Menge an Kundendaten, berechnen nach entsprechenden Voreinstellungen die 
abzurechnenden Kosten und sind meist auch fur die Rechnungserstellung als sol- 
che zustandig. 

Bei den bekannten Abrechnungs- und Kundenverwaitungssystemen wird eine zen- 
trale Datenbank eingesetzt die insbesondere zur Speicherung aller Anwendungs- 
daten dient. Diese ist jedoch meist als relationale Datenbank ausgebildet und stellt 
so zugleich den Hauptserver des Systems dar. Uber Clients, und insbesondere 
iiber GUIs (Graphic User Interfaces), werden dem Anwender bestimmte Dienstlei- 
stungen des Kundenverwaltungs- und Abrechnungswesens ermoglicht. Dabei kon- 
nen zusatzliche Anwendungsserver zwischen die Clients und die Datenbank ge- 
schaltet sein. Jeder Client bzw. jeder Anwendungsserver ist mit der zentralen Da- 
tenbank verbunden, von der alle zur Anwendung notigen Daten abgefragt und ge- 
andert werden konnen. 
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Zum besseren VerstSndnis wird im folgenden zunachst ein typisches Ausfuhrungs- 
beispiel eines vorbekannten Abrechnungs- und Kundenverwaltungssystems im Be- 
reich der Mobilfunk-Telekommunikation unter Bezugnahme auf Fig. 1 erlautert. An 
diesem Beispiel sollen die Ablaufe innerhalb eines derartigen Systems und die 
Moglichkeiten, die das System liefern sollte, vereinfacht dargestellt werden. 

Das System 14 weist eine zentrale, relationale Datenbank 17 auf, die gleichzeitig 
den Hauptserver des Systems 14 bildet und mit einer Mehrzahl von Modulen 3 liber 
ein Netzwerk in Verbindung steht. Die Module 3 konnen jeweils entweder als Client 
Oder als Anwendungsserver mit angehangten Clients ausgebildet sein und bieten 
dem jeweiligen Nutzer uber GUIs Oder Programmierschnittstellen die Mdglichkeit, 
im voraus festgelegte Dienstleistungen aus dem Abrechnungs- Oder Kundenverwal- 
tungsbereich in Anspruch zu nehmen. Die dazu notigen Datensatze sind in Tabel- 
len der zentralen Datenbank 17 gespeichert und werden von dort abgerufen. 

Aktive Mobil-Vermittlungsstellen (MSC: Mobile Switching Center) 32 ermitteln und 
speichern Gesprachsdaten wie Ursprung, Ziel, Dauer und Dienst von Mobiltelefona- 
ten. Die Informationen werden in das Abrechnungs- und Kundenverwaltungssystem 
14 eingelesen und dort von geeigneten Abrechnungsmodulen 20 bearbeitet, welche 
die Gesprachsgebuhren berechnen (Rating). Die dazu erforderlichen Daten werden 
aus der zentralen Datenbank 17 abgerufen, und nach Ablauf des Abrechnungspro- 
zesses werden die neu ermittelten Daten wieder in der Datenbank 17 gespeichert. 
Diese Daten konnen wiederum von einem Rechnungserstellungsmodul 22 abgeru- 
fen werden, mit dessen Hilfe der Provider die Kundenrechnungen erstellen kann 
(Billing). Die Kundenverwaltung als solche (Customer Care) wird ebenfalls anhand 
mehrerer Module, die jeweils fur unterschiedliche Dienstleistungen verwendet wer- 
den, durchgefuhrt. Beispielsweise konnen uber ein Modul 24 Angaben uber freie 
Ressourcen an SIM-Karten-Verkaufer 34 weitergeleitet werden. Ebenso benotigt 
ein Provider Module 26 zur Abwicklung von Geldgeschaften mit Banken und Kre- 
ditkartenunternehmen 36 sowie Module 28 fur die Ubermittlung von Daten an ein 
Teilnehmerregister (HLR: Home Location Register) 30 des Mobilfunknetzes, in dem 
Daten von Teilnehmern gespeichert werden. 
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Alle Module 3 sind direkt mit der zentralen Datenbank 17 verbunden, konnen un- 
tereinander jedoch nicht uber direkte Schnittstellen kommunizieren. Die Schnittstel- 
len zwischen den Modulen 3 sind ublicherweise uberhaupt nicht explizit definiert. 
Statt dessen dient die zentrale Datenbank 17 als eine grofte implizite Schnittstelle 
zwischen alien verschiedenen Modulen 3, wodurch eine Vielzahl unnotiger interner 
Unterabhangigkeiten verursacht wird. Die Schnittstelle wird demnach durch einen 
Satz an Datenbanktabellen dargestellt. In derartigen Systemen 14 wird die Daten- 
bank 17 auBerdem zumeist auch als Server dazu verwendet, die Geschaftslogik in 
den verschiedenen Modulen 3 zu konfigurieren, dient neben der Datenspeicherung 
zusatzlich als Schnittstelle zu externen Systemen und zur Kommunikation zwischen 
den Modulen 3. . 

Im Telekommunikationsbereich sind in den letzten Jahren durch die rasante Ent- 
wicklung neuer Technologien (Handy, WAP-Handy etc.) extrem groBe Veranderun- 
gen innerhalb kiirzester Zeiten zu verzeichnen. Da zudem der Markt fur den freien 
Wettbewerb geoffnet ist, werden potentielle Kunden (Subscriber) von vielen Anbie- 
tern (Providern) immer starker umworben. Daher ist es fur einen Provider unum- 
ganglich, Veranderungen flexibel Rechnung zu tragen und schnell auf die Erfor- 
dernisse des Marktes einzugehen. Im selben Mafte steigen mit der Anzahl an 
Subscribern und der Vielfalt der technologischen Moglichkeiten auch die Anforde- 
rungen an Abrechnungs- und Kundenverwaltungssysteme. 

Nachteilig an den vorbekannten Systemen ist, daS fur Modifikationen oder Erweite- 
rungen bei Anderungen im Anspruchsprofil des Systemnutzers immer der Code 
des entsprechenden Systems geandert werden mud. Dadurch entstehen sowohl 
erhohte Personalkosten als auch eine enorme Verzogerung bei der Anpassung des 
Systems an die Markterfordernisse. 

Dier vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Abrechnungs- 
und Kundenvenwaltungssystem, insbesondere fur Kommunikationsdienste, zu 
schaffen, bei dem Anderungen oder Erweiterungen des Systems aufgrund gean- 
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derter Wunsche des Systemnutzers moglichst schnell mit moglichst geringem Pro- 
grammieraufwand durchgefuhrt werden konnen. 

Diese Aufgabe wird durch die Merkmale des Anspruchs 1 gelost. 

Dadurch, daft das System eine verteilte Komponentenarchitektur aufweist, in der 
entsprechend den angebotenen Dienstleistungen Komponenten ausgebildet sind, 
die iiber Schnittstellen direkt miteinander kommunizieren konnen, wird eine flexible 
Konfiguration der Geschaftslogik ermoglicht, so daB Kundenwunschen mit einem 
Minimum an Implementationsveranderungen nachgekommen werden kann. Zudem 
laBt sich das System auBerst flexibel und leicht an eine Erhohung der Anzahl der 
zu verarbeitenden Daten anpassen. 

Vorteilhafterweise ist das System in mindestens zwei hierarchisch angeordnete 
Schichten (Layers) mit zunehmendem Abstraktionsgrad unterteilt. Jede Schicht 
isoliert die uber ihr liegende Schicht nach unten, so daB der daruberliegenden 
Schicht Implementierungsdetails der darunterliegenden Schichten verborgen blei- 
ben. In der bevorzugten Ausfuhrungsform des erfindungsgemafJen Abrechnungs- 
und Kundenverwaltungssystems ist das System unterteilt in Basisschicht (Base 
Layer), allgemeine Schicht (Common Layer), technische Unterstutzungsschicht 
(Technical Services Layer), Anwendungsschicht (Application Layer) und Ge- 
schaftsschicht (Business Layer). 

Besonders vorteilhaft macht es sich bemerkbar, dad das System in mindestens 
zwei hierarchisch angeordnete Ebenen (Tiers) entsprechend den technischen Auf- 
gaben unterteilt ist. In verschiedenen logischen Ebenen konnen Prozesse gleich- 
zeitig und unabhangig voneinander ablaufen; zudem ist eine noch feinere Eintei- 
lung in physikalische Ebenen moglich. In der bevorzugten Ausfuhrungsform des 
erfindungsgemaBen Abrechnungs- und Kundenverwaltungssystems ist das System 
unterteilt in Prasentationsebene (Presentation Tier), Anwendungsebene 
(Application Tier), Meta-Anwendungsebene (Meta-Application Tier), Domainebene 
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(Domain tier), Persistenzebene (Persistence tier) und Datenbankebene (Database 
Tier). 

Ober die Meta-Anwendungs-Ebene (Meta-Application Tier) werden einer Anwen- 
dung innerhalb des Systems vorteilhafterweise Mittel zur Verfugung gestellt, um 
sich selbst zu beschreiben. Dies erlaubt eine dynamische (d.h. zur Laufzeit durch- 
fuhrbare) Konfiguration des Verhaltens der einzelnen Komponenten. 

Besonders vorteilhaft weist das System ein Meta-Anwendungs-Dictionary (Meta- 
Application Dictionary) auf, wodurch der Programmieraufwand bei Anderungen auf 
Serverseite sehr gering gehalten werden kann. 

In einer vorteilhaften Weiterbildung weist das System Einrichtungen auf, die das 
Schnittstellenmodell des Servers auf der Clientseite zur Verfugung stellen und 
damit die eingesetzte Kommunikationstechnologie vor einem Client-Entwickler ver- 
bergen. 

Vorteilhafterweise bietet das System definierte Schnittstellen und Mechanismen zur 
Anfrageverteilung an, so daR mehrere gleichartige Anwendungsserver dem System 
hinzugefugt werden konnen, wodurch die mogliche Anzahl an zu verarbeitenden 
Daten mit geringem Aufwand nahezu beliebig erhoht werden kann, ohne die Verar- 
beitungsgeschwindigkeit zu beeintrachtigen. 

Das System bietet in vorteilhafterweise die Moglichkeit, Komponenten auszutau- 
schen oder hinzuzufugen, so daU das System nicht veraltet und auf einfache Weise 
andere Oder zusatzliche Dienstleistungen anbieten kann, ohne daft das komplette 
System ausgetauscht werden mud oder tiefgreifende Codeanderungen vorgenom- 
men werden mussen. Somit ist auch die Erstellung von Upgrades relativ kosten- 
gunstig und einfach. 
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Dte Moglichkeit der Erweiterung von Klassen und/oder des Hinzufugens neuer 
Klassen liefert den Vorteil, eine Komponente wahrend der Ausfuhrung unter Ver- 
wendung von Meta-Anwendungs-Einrichtungen verandern zu konnen. 

Vorteilhafterweise wird die Arbeitsteilung innerhalb des Systems dadurch gefordert, 
daft die Datenbank in eine Vielzahl von unabhangigen Datenbankabschnitten auf- 
geteilt ist und/oder mehrere voneinander getrennte Datenbanken existieren, die 
jeweils mit lediglich einer Komponente kommunizieren. 

Vorteilhaft stellt das System Mechanismen zur Verfugung, die ein uber Komponen- 
ten verteiltes Transaktions- und Speichermanagement ermoglichen, wodurch die 
Robustheit und Zuverlassigkeit des Gesamtsystems sichergestellt wird. 

Weitere Einzelheiten, Merkmale und Vorteile der Erfindung ergeben sich aus der 
nachfolgenden Beschreibung unter Bezugnahme auf die Zeichnungen. Darin zeigt: 

Fig. 2 eine schematische Darstellung des Aufbaus einer Ausfuhrungsform des 
erfindungsgemafJen Abrechnungs- und Kundenverwaltungssystems; 

Fig. 3 eine schematische Darstellung der systeminternen Architektur einer be- 
vorzugten Ausfuhrungsform des erfindungsgemaBen Abrechnungs- und 
Kundenverwaltungssystems mit der Unterteilung in Schichten mit zuneh- 
mendem Abstraktionsgrad und in Ebenen entsprechend den technischen 
Aufgaben; 

Fig. 4 eine schematische Darstellung der Kommunikationsmoglichkeiten zwi- 
schen Servern und Clients in der bevorzugten Ausfuhrungsform des er- 
findungsgemaBen Abrechnungs- und Kundenverwaltungssystems von 
Fig. 3; und 
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Fig'. 5 schematische Darstellungen des Aufbaus eines vorbekannten Systems, 
einer ersten und einer zweiten Ausfuhrungsform des erfindungsgemaSen 
Abr chnungs- und Kundenverwaltungssystems, 

In Fig. 2 ist ein schematisches Modell einer ersten Ausfuhrungsform des erfin- 
dungsgemaRen Abrechnungs- und Kundenverwaltungssystems 1 dargestellt. In 
diesem System 1 dient eine Datenbank 7 lediglich zur permanenten Speicherung 
von Daten, die spater wieder abgerufen werden konnen. Die ubrigen oben genann- 
ten Funktionen von Datenbanken 17 t die in vorbekannten Systemen 14 eingesetzt 
werden, werden nun grofttenteils von der Anwendungslogik ubernommen. Entspre- 
chend der jeweils angebotenen Dienstleistungen im Bereich des Abrechnungs- 
bzw. Kundenverwaltungswesens sind Komponenten 5 ausgebildet, die miteinander 
uber gemeinsame Schnittstellen kommunizieren konnen und nicht die Datenbank 7 
als Schnittstelle verwenden mussen. Damit wird ein schnellerer Informationsaus- 
tausch zwischen den einzelnen Anwendungen ermoglicht, und durch die Abtren- 
nung der Anwendungslogik aus der Datenbank 7 eine Struktur erreicht, die flexibel, 
erweiterbar und fur eine Verarbeitung von grolien Datenmengen geeignet 1st. Ver- 
anderungen Oder Erweiterungen des Systems 1 k6nnen dabei ohne gro&en Pro- 
grammieraufwand vorgenommen werden. Durch diese Struktur ist es moglich, je- 
des Problem nur einmal zu losen, und die Losung auf einfache Weise fur alle Kom- 
ponenten 5 des Systems 1 verfugbar zu machen. Gleichzeitig ist fur nahezu jede 
implementierte Losung sichergestellt, da(i sie nicht nur ein bestimmtes festgelegtes 
Problem lost, sondern immer eine Kategorie von Problemen. 

Zur besseren Verdeutlichung des Begriffs "Komponente" in der Praxis soil im fol- 
genden an einem Beispiel aus dem Telekommunikationsbereich die Aufteilung der 
Dienstleistungen im Bereich Kundenverwaltung in einzelne Komponenten 5 darge- 
stellt werden. Eine Moglichkeit der Einteilung des Systems 1 liefert etwa folgende 
Komponenten 5: 

Risk Management, 
Fraud Management, 
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Trouble Ticket Management, 
Address Managem nt, 
Accounts Receivable, 
Document Management, 
Task Management, 
Order Management, 
Product Management und 
Inventory Management. 

Mit Hilfe der Komponente "Risk Management" kann der Systemnutzer die Kredit- 
wurdigkeit von Kunden uberprufen. Die Komponente "Fraud Management" wird zur 
Betrugsdetektion eingesetzt. Aufgedeckt werden dabei UnregelrnalSigkeiten oder 
starke Abweichungen vom ublichen Verhalten des Kunden, etwa wenn eine hohe 
Anzahl an Auslandsgesprachen bei einem Kunden festgestellt wird, der bisher nie 
ins Ausland telefoniert hat. In der Komponente "Trouble Ticket Management" wer- 
den Beschwerden von Kunden und Storungsmeldungen vom Netz selbst registriert 
und bearbeitet. Mit Hilfe der Komponente "Address Management" wird ein Adress- 
register verwaltet, das die Prufung der Plausibilitat einer Adresse erlaubt. Die Kom- 
ponente "Accounts Receivable" kann als eine Art Schuldbuchhaltungskomponente 
aufgefaSt werden. Mit ihrer Hilfe werden Zahlungseingange registriert, offene 
Rechnungen aufgedeckt und Konten ausgeglichen. Die Komponente "Document 
Management" steht zur Verwaltung von Kundendokumenten (Briefe, Faxe etc.) 
bereit. Durch die Dienstleistungen der Komponente "Task Management" werden 
nach Eingang von Auftragen die entsprechenden Arbeitsauftrage erteilt. Die Kom- 
ponente "Order Management" ist fur Auftragsbearbeitung und Kundenverwal- 
tungsdienstleistungen zustandig. Mit Hilfe der Komponente "Product Management" 
kann der Endverbraucher uber die Verfugbarkeit von Produkten und uber Preisli- 
sten informiert werden. Die Komponente "Inventory Management" ist fur die Be- 
standsfiihrung zustandig, d.h. mit ihrer Hilfe ist eine Verwaltung der vergebenen 
und freien Telefonnummern, SIM-Karten oder anderer Gegenstande moglich. Jede 
der genannten Komponenten 5 erftillt eine relativ grofce Anzahl an Dienstleistun- 
gen. Wie bereits oben erwahnt konnen die Komponenten 5 uber direkte Schnittstel- 
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ten Daten untereinander austauschen. Wenn also beispielsweise die Komponente 
"Accounts Receivable" spezielle Kundendaten benotigt, greift sie nicht mehr auf 
Daten aus der Datenbank zuriick, sondern erhalt die erforderlichen Daten direkt 
von der Komponente "Order Management 1 ' oder entsprechenden anderen Kompo- 
nenten. 

Das Komponentenmodell fur ein Abrechnungs- und Kundenverwaltungssystem 1 
setzt voraus, dad eine grundlegende Funktionalitat in einem zentralisierten Frame- 
work 10 verfugbar ist. Jede einzelne Komponente 5 ist von alien anderen Kompo- 
nenten unabhangig. Allerdings sind die Komponenten angewiesen auf einen Satz 
von Dienstleistungen, um korrekt arbeiten zu konnen. Diese benotigten Dienstlei- 
stungen konnen auch von Komponenten anderer Hersteller geliefert werden. Dann 
ist es mdglich, diese in ein System mit den systemeigenen Komponenten zu inte- 
grieren. 

Das vorliegende System 1 ist jedoch nicht als rein dienstleistungsbasierendes Mo- 
dell ausgebildet, sondern weist auch etliche Elemente eines eher objektorientierten 
Modells auf. Auf Einzelheiten wird spater noch genauer eingegangen. 

Es existieren zahlreiche Definitionen des Begriffs "Komponente" in der objektorien- 
tierten Programmierung. Diejenige, die den in der Praxis im vorliegenden Abrech- 
nungs- und Kundenverwaltungssystem 1 verwendeten Komponenten 5 am nach- 
sten kommt, lautet: 

"Eine Komponente ist eine Konstruktionseinheit mit vertraglich spezifizierten 
Schnittstellen und (wenn moglich) lediglich expliziten Kontextabhangigkeiten. Eine 
Softwarekomponente kann unabhangig eingesetzt werden und ist Gegenstand fur 
eine zusammengesetzte Konstruktion mit Produkten Dritter. " 

Die Hauptaspekte dieser Definition sind, daB eine Komponente 5 unabhangig von 
anderen Komponenten aufgestellt und eingesetzt werden kann, daB eine Kompo- 
nente 5 von anderen Anbietern verwendet werden kann, um Abrechnungs- oder 
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Kuhdenverwaltungssysteme zu bilden, und daft eine Komponente 5 lediglich 
Schnittstell n beinhaltet, d.h. keinen Zustand im ublichen Sinne des Wortes auf- 
weist, obwohl eine Komponente 5 Eigenschaften haben kann und bestimmte ex- 
plizite Anspruche innerhalb eines Kontexts an ihren Einsatz stellt. 

Die Komponenten 5 im vorliegenden System 1 sind in der Regel relativ umfassend. 
Das folgt daraus, daft eine Komponente 5 unabhangig innerhalb eines bestimmten 
Kontexts eingesetzt werden kann und daher ausreichend abgeschlossen sein muft. 
Allerdings sind auch Komponenten 5 mit lediglich einer Schnittstelle moglich. 

Komponentenschnittstellen sind in erster Linie dienstleistungsbasierend. Unter der 
Voraussetzung, daft eine Komponente 5 keinen Zustand besitzt, liefern die 
Schnittstellen, die von einer Komponenteninstanz geschaffen werden, Dienstlei- 
stungen und senden keine Information uber den Status der Komponente 5 zuruck. 
Die Anzahl der Dienstleistungen bzw. Schnittstellen, die von einer Komponente 5 
geliefert werden, muft der Zahl entsprechen, die notig ist, um den Satz an Verhal- 
ten vollstandig zu veroffentlichen, der innerhalb der Komponente 5 zusammenge- 
faftt ist. 

Wie bereits oben erwahnt, verwendet das vorliegende Komponentenmodell in er- 
ster Linie Dienstleistungen, insbesondere um den Einsatz von Komponenten 5 mit 
Komponenten anderer Hersteller zu ermoglichen. Andererseits verwendet das vor- 
liegende Abrechnungs- und Kundenverwaltungssystems 1 zwischen den fur dieses 
System entwickelten Komponenten 5 zusatzlich eine traditionellere, objektorientier- 
te Modellmdglichkeit, bei der Komponenten 5 ihre internen Klassen fur den Ge- 
brauch durch andere Komponenten veroffentlichen, was eher einer Peer-to-Peer- 
Architektur entspricht. 

Um Clients direkten Zugang zu den Objekten innerhalb einer Komponente 5 und 
deren Benutzung zu ermoglichen, wird eine zusatzliche Losung mit Peer-to-Peer- 
Objekten angeboten, so daB GUI-Entwickler auf einfache Weise mit modernen 
Werkzeugen arbeiten konnen, die auf einem model-view-artigen Pattern basieren. 
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Die Komponenten 5 existieren also als einzelne abgeschlossene Einheiten inner- 
halb eines Systems. Die technische Grundlage fur Ausfuhrung und Kommunikation 
wird durch ein Framework 10 geliefert. Das Framework 10 ist Teil des gesamten 
Systems 1, das durch die geschaftsspezifische Logik komplettiert wird. Details uber 
die Architektur des Systems 1 werden in der Beschreibung zu Fig. 3 erlautert. 

Komponenten 5 kommunizieren miteinander, wobei sie veroffentlichte Dienstlei- 
stungen verwenden, besitzen aber ebenso Anforderungen an den Kontext, d.h. das 
ganze Verhalten, auf das eine Komponente 5 angewiesen ist, und das nicht in der 
Komponente 5 selbst implemented ist, kann von anderen Komponenten Oder vom 
Framework stammen. Ein Hauptmerkmal des Frameworks betrifft die Abgeschlos- 
senheit, d.h. das Framework liefert den Behalter fur. die Ausfuhrung einer Kompo- 
nente 5. AuBerdem erlaubt die Struktur des Komponentendesigns das einfache 
Packen von Anwendungselementen zum Zwecke der Abgeschlossenheit. 

Die Struktur der Komponentensoftware ist daher folgenderma&en: Geschaftsdo- 
mainklassen werden in Pakete gruppiert, wobei ein Paket eine relativ feine logische 
Domain darstellt. Diese Pakete werden in Komponenten 5 gruppiert, so daft Pakete 
in einer Komponente 5 Klassen enthalten, die sich bis zu einem gewissen Grad 
gegenseitig benutzen, wahrend Pakete in getrennten Komponenten 5 sich gegen- 
seitig so wenig wie moglich benutzen. Schliedlich werden Komponenten 5 zusam- 
men in Servern gruppiert. Diese Gruppierung kann freigestellt sein, wobei es gun- 
stig ist, wenn Komponenten 5, die oft miteinander kommunizieren, im selben Server 
zusammengefaBt sind. Zur Verbindung mit fremden Frameworks ist es notig, so 
viele Abhangigkeiten als moglich zwischen der Ausfuhrungsumgebung und einer 
Komponente 5 zu entfernen. Daher benotigt jede Komponente 5 ihre eigene globa- 
le AbstractFactory-lnstanz; dies kann nicht pro Server geschehen, da es nicht ga- 
rantiert ist, daS die Komponente 5 innerhalb dieses Servers laufen wird. 

Eines der Hauptkonzepte im Framework, die es zu einem Komponentenframework 
machen, ist die AbstractComponent-Klasse. Diese Klasse beinhaltet die Attribute 
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und das Verhalten, die alien Komponenten 5 gemeinsam sind. Spezifische Kompo- 
nenten 5 sind Unterklassen dieser Klasse. Da die Dienstleistungen, die von einer 
Komponente 5 geliefert werden, in Transaktionen involviert sind ( und vielfache 
Komponentendienstleistungen in einer Transaktion verwickelt sein kdnnen, ist die 
AbstractComponent-Klasse transaktional. 

Die Unterklassen der AbstractComponent-Klasse, die eigentlichen Komponenten 5, 
enthalten alle Dienstleistungen, die fur die Komponente 5 spezifisch sind. Ein wei- 
teres wesentliches Merkmal jeder Unterklasse ist eine Instanz einer Fassadenklas- 
se fur jede externe Komponente, mit der die Komponente 5 kommuniziert 

Dienstleistungen an den Komponentengrenzen bzw. Dienstleistungen, die in ande- 
ren Komponenten implementiert sind, werden intern mittels Fassadenobjekten mo- 
delliert. Die Dienstleistungen in den Fassaden sind diejenigen, die die Komponente 
5 benotigt, urn zu funktionieren. Beispielsweise weist Komponente "A" intern eine 
"B"-Fassadeninstanz und eine M C"-Fassadeninstanz auf, wenn sie Schnittstellen in 
den Komponenten "B H und "C" verwendet. Das Design und die Implementation der 
Komponente "A" konnen dann groBtenteils unabhangig von den Komponenten "B" 
und "C" ausgefuhrt werden. Wenn die Komponenten 5 eingesetzt werden, mussen 
die Dienstleistungen in den Fassaden in geeignete Dienstleistungen in anderen 
Komponenten abgebildet werden. 

In einer bevorzugten Ausfuhrungsform des Abrechnungs- und Kundenverwaltungs- 
systems 1 sind diese Fassaden derart implementiert, da& das Mappen einer Fas- 
sadendienstleistung zu einer eigentlichen Komponentendienstleistung ohne Ande- 
rung des Codes ausgefuhrt werden kann. Aus diesem Grund existiert eine abstrak- 
te Klasse, die generelles Verhalten beinhaltet, die AbstractFacade-Klasse. Sowohl 
fur veroffentlichte Domainobjekte als auch fur Komponenten 5 unterstutzt das Fra- 
mework 10 Transaktionen zwischen Komponenten 5. Fur Dienstleistungspropaga- 
tion von Komponente zu Komponente wird implizite Propagation verwendet. Im 
Bereich Speicherverwaltung werden die Transaktionskontexte fur nicht transakti- 
onsbezogene Zwecke verwendet. 
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Zusammenfassend laftt sich nochmals feststellen, da& die hier dargestellte bevor- 
zugte AusfGhrungsform des Abrechnungs- und Kundenverwaltungssystems 1 zum 
einen Dienstleistungen in Komponentenfassaden verwendet, wenn Dienstleistun- 
gen fur externe Komponenten geliefert werden mussen. Ebenso veroffentlichen 
jedoch Komponenten 5 ihre internen Klassen far die Benutzung durch andere sy- 
steminterne Komponenten 5. 

In Fig. 3 ist die Einteilung des Systems 1 in hierarchisch angeordnete Schichten 
(Layers) mit zunehmendem Abstraktionsgrad und in Ebenen (Tiers) entsprechend 
den technischen Aufgaben unterteilt Die Schichten und Ebenen in der Architektur 
des Systems 1 liefern eine zweidimensionale Matrix. Allerdings ist diese Untertei- 
lung in der Paketstruktur des Frameworks 10 nicht explizit reprasentiert. 

Jede Schicht (Layer) ist von den komplizierten Belangen der darunterliegenden 
Schichten isoliert, so daft eine Kommunikation zwischen den Schichten nur mittels 
Benutzung von Standardschnittstellen implementiert wird. Dadurch wird ein hoher 
Grad an Flexibility und Unabhangigkeit gewahrleistet. 

In einer bevorzugten Ausfuhrungsform ist das System 1 in fiinf Schichten unterteilt. 
Die unterste Basisschicht (Base Layer) 40 beinhaltet dabei Klassen, die grundle- 
gendes Verhalten liefern, wie Systemressourcen, Betriebssystem und hardware- 
spezifische Klassen. Die Schicht beinhaltet auch das Verhalten, das von benutzter 
Drittsoftware erlangt wird. In der bevorzugten Ausfuhrungsform sind hierbei insbe- 
sondere die Grundlagen von CORBA, einer gemeinsamen Standardarchitektur fur 
Objektanforderungsvermittler, sowie von TopLink, einer objektsbezogenen Einrich- 
tung zum Abbilden, beinhaltet. Als Programmiersprache wird in dieser Ausfuh- 
rungsform Java verwendet. 

In der daruber angeordneten allgemeinen Schicht (Common Layer) 42 sind Ab- 
straktionen von Klassen der Basisschicht 40 sowie Klassen beinhaltet, die allge- 
meine Einrichtungen fur alle Schichten und Ebenen liefern. Darin sind auch Ele- 
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mernte fur das Mitprotokollieren (Logging) und fur die Fehlerbehandlung (Exception 
handling) beinhaltet. 

Daruber angeordnet ist die technische Unterstiitzungsschicht (Technical Services 
Layer) 44, die Klassen beinhaltet, die software-technische Dienste anbietet. 

Die daruber liegende Anwendungsschicht (Application Layer) 46 enthalt alle Klas- 
sen und das Verhalten fur eine dynamische Definition der Elemente einer Anwen- 
dung bzw. einer Komponente 5 auf einem Meta-Level. Instanzen dieser Klassen 
werden bei Interaktionen mit einer echten Anwendung verwendet. Die Dienste der 
technischen Unterstiitzungsschicht 44 werden zu einer abstrakten Anwendung zu- 
sammengefaBt und Mechanismen zur Beschreibung der Elemente der Domaine- 
bene 58 auf einer Meta-Ebene erlaubt. Die Anwendungsschicht 46 beinhaltet die 
Klassen, die den hochsten Level an Abstraktion im System reprasentieren, bei- 
spielsweise die Factory, die verschiedene Dienstleistungen von den darunterlie- 
genden Schichten verwendet, wie etwa Transaktions- und Persistenzunterstutzung. 

Die Gesamtheit der Elemente von der Basisschicht 40 bis hin zu Teilen der An- 
wendungsschicht 46 kann auch als (technisches) Framework 10 bezeichnet wer- 
den. Erst durch die Geschaftsschicht (Business Layer) 50, die die spezifischen 
Klassen fur das Verhalten einer Anwendung und einer Komponente 5 enthalt, und 
in der die tatsachlichen dienstleistungsspezifischen Vorgange programmiert wer- 
den, wird das System 1 komplettiert. 

Durch die Isolation der einzelnen Schichten ist realisiert, daB beispielsweise die 
Tatigkeit eines Business-Logik-Entwicklers nicht von einer Anderung in einer darun- 
terliegenden Schicht (etwa einer Anderung des Betriebssystems) beeinfluBt wird. 

Das System 1 ist zudem in verschiedene Ebenen (Tiers) unterteilbar. Dabei ist zwi- 
schen der Aufteilung in logische und physikalische Ebenen zu unterscheiden. Die 
Aufteilung des Systems in zwei logische Ebenen (dicke Clients) bzw. drei logische 
Ebenen (dunne Clients) wird vorgenommen, da in verschiedenen logischen Ebenen 
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Vefrarbeitungsprozesse unabhangig voneinander und gleichzeitig ablaufen konnen. 
In der vorliegenden bevorzugten Ausfuhrungsform ist das System zudem in eine 
feiner Ebenenstruktur nach physikalischen Ebenen unterteilt. 

Die oberste und damit die dem Systemnutzer nachste Ebene ist dabei die Prasen- 
tationsebene (Presentation Tier) 52. Obwohl der Server eigentlich nicht mit der 
Prasentationsebene 52 in Verbindung steht, mud sein Framework 10 dennoch eini- 
ge Einrichtungen liefern, mit denen die Objekte der Prasentationsebene 52 kom- 
munizieren konnen, und zudem bestimmen, wie prasentationsspezifisches Verhal- 
ten behandelt werden muft. Die Elemente der Presentation betreffen die Represen- 
tation von Informationen, die Navigation durch diese Informationen und deren Ma- 
nipulation. Das Framework 10 des Servers setzt die Verwendung einer objektorien- 
tierten Anwenderschnittstelle voraus und liefert entsprechende Einrichtungen. Die 
Elemente der Prasentationsebene 52 verwenden die beschreibende Information, 
die in Meta-Anwendungs-lnstanzen geliefert wird, um Aspekte zu definieren, wie 
Geschaftsobjekte und ihre Attribute betrachtet Oder verwendet werden sollen. Die- 
se Meta-Anwendungs-lnformation liefert eine Isolationsschicht zwischen den Pra- 
sentationsobjekten (Fenstern) und Anwendungs- oder Geschaftsobjekten. Eine 
zusatzliche Isolationsschicht kann durch Zugangsprivileg-Einrichtungen erreicht 
werden, die Serverelemente zeigen Oder verstecken. 

Die Anwendungsebene (Application Tier) 54 beinhaltet Klassen und Schnittstellen, 
die die Anwendung reprasentieren, sowie Klassen, die auf Anwendung bezogenes 
Komponentenverhalten in Pakete packen. Enthalten sind eine Anzahl von Klassen, 
die fur die Interaktion mit einer Anwendung notwendig sind, sowie die fundamentale 
abstrakte Klasse fur Anwendungskontrollklassen und AnwendungsprozeRklassen. 
Diese Klassen bilden die Hauptschnittstelle fur Clients innerhalb der Applikationen. 
Sie liefern die fundamentalen Mechanismen fur Kommunikation mit der Applikation, 
indem sie Instanzen von gewunschten Objekten erzeugen, und erlauben die Navi- 
gation zu diesen Objekten. 
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ZuSammenfassend la&t sich deshalb vereinfacht sagen, dad die Anwendungsebe- 
ne 54 die Klassen enthalt, die Geschaftsprozesse modellieren, welche zugrunde- 
liegende Geschaftsobjekte verwenden. Der GroBteil der individuellen Einstellungs- 
arbeit ist daher in dieser Ebene isoliert. 

Zudem enthalt die Anwendungsebene 54 die Fassadenobjekte, die die Hauptein- 
richtungen fur die Kommunikation zwischen Komponenten 5 darstellen. 

Die Klassen in der Meta-Anwendungsebene (Meta-Application Tier) 56 liefern einer 
Anwendung Einrichtungen, um sich selbst zu beschreiben und zu andern. Die Me- 
ta-Anwendungsebene 56 besteht aus Klassen, die die Definition von Informationen 
bezuglich Aspekten von Anwendungsobjekten und Domainobjekten erlauben. Die- 
se Klassen machen es moglich, Aspekte von Geschaftsobjekten dynamisch auf 
einem Meta-Level zu konfigurieren. Solche Aspekte beinhalten die Betitelung von 
Klassen, beinhalten weiter Formatrriasken und Langen fiir Attribute, beinhalten In- 
formationen, ob bestimmte Attribute obligatorisch sind usw. 

Die Meta-Anwendungs-Einrichtungen liegen auf einem hoheren Level als die An- 
wendungen und liefern generelle Funktionalitat, die auf alle Anwendungen an- 
wendbar ist. 

Die Domainebene 58 weist die Geschaftsobjektklassen (business object classes) 
einer spezifischen Anwendungsdomain auf. In anderen Worten ist die Domainebe- 
ne 58 die Ebene, die als einzige Klassen beinhaltet, welche die Geschaftsdomain 
einer Anwendung modellieren. Daher beschrankt sich der Arbeitsbereich fur An- 
wendungsentwickler grodtenteils auf diese Ebene. 

Die Domainebene 58 besteht nahezu ausschliefMich aus einer abstrakten Domain- 
klasse, von der alle Geschaftsobjekte ihr Verhalten vererbt bekommen. Zudem 
enthalt die Domainebene 58 Domainklassen, die jeweils Unterklassen der oben 
genannten abstrakten Klasse darstellen. Diese Klassen modellieren stabiles, nicht 
veranderliches Verhalten der zentralen Klassen einer Problemdomain. Jedes un- 
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bestandige Verhalten, das eine Domainklasse betrifft, ist in Klassen zusammenge- 
faftt, die der Anwendungsebene 54 zugerechnet werden, aber durch die Domain- 
klassen benutzt werden. 

Die Persistenzebene (Persistence Tier) 60 ist die Ebene, die die Interaktionen zwi- 
schen Domainobjekten und einem persistenten Speicher zusammenfaRt. Somit 
beinhaltet sie das Verhalten, das Persistenz fur Objekte liefert, namlich ihre Spei- 
cherung und das Abrufen. Die Ebene beinhaltet ebenso die Klasse, die die Verbin- 
dungen mit der Datenbank 7 verwaltet. Insgesamt stellt sie zum einen eine Abbil- 
dung des Klassenmodells der Domainebene 58 auf das Datenmodell der Daten- 
bank 7 dar und zum anderen unterstiltzt sie Mechanismen zur transaktionsgesi- 
cherten Manipulation der Daten in der Datenbank 7. 

Die Funktionen der Datenbankebene 62 wurden bereits oben ausfuhrlich beschrie- 
ben. 

Die verschiedenen Variationsmoglichkeiten auf Server- bzw. Clientseite mit dem 
Ziel von VerSnderungen Oder Erweiterungen des Systems 1 lassen sich am besten 
anhand des Schemas in Fig. 4 verdeutlichen. Aufbauend auf dem Framework 10 
sind Clientseite 70 und Serverseite 71 gesondert abgebildet Auf der Serverseite 71 
sind die Geschaftsschichtobjekte 72, die Anwendungsschichtobjekte 74 und die 
Meta-Anwendungsschichtobjekte 76 anskizziert. Auf Clientseite 70 sind die erfor- 
derlichen Schnittstellen 66, insbesondere GUIs, ebenso enthalten wie speziell aus- 
gebildete JavaBeans 68. Die Pfeile skizzieren die jeweiligen Wechselwirkungsmog- 
lichkeiten zwischen Client und Server bzw. innerhalb des Clients. 

Durch die spezifisch ausgebildeten JavaBeans 68 konnen auf Clientseite 70 vorge- 
fertigte GUI-Einrichtungen erzeugt werden, so daB der Systemnutzer uber Benut- 
zerschnittstellen Einstellungen vornehmen kann, wodurch der Programmierauf- 
wand reduziert wird. Durch ihre Verwendung ist es moglich, das Schnittstellenmo- 
dell des Servers auf Clientseite 70 zur Verfugung zu stellen und damit die einge- 
setzte Kommunikationstechnologie vor einem Client-Entwickler zu verbergen. 
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Somit bekommt der Systemnutzer Schnittstellen zur Verfugung, an denen er sich 
anhangen kann, um seine Sonderwunsche zu implementieren. Dies geschieht an 
speziellen lokalisierten Stellen, so daB kein grundlegender Code geandert werden 
muB. 

Besonders hilfreich bei der DurchfCihrung dieses Vorhabens ist das Meta- 
Anwendungs-Dictionary. Dieses beinhaltet eine grolie Menge an Informationen 
uber eine Anwendung, ihre Klassen und die Attribute in den Klassen, weshalb das 
Meta-Anwendungs-Dictionary die dynamische Konfiguration von Anwendungsin- 
formationen und Verfahrensablaufen auf einem Meta-Level erlaubt. Das eigentliche 
Dictionary wird durch eine Instanz reprasentiert, die als Root des Dictionary's fun- 
giert und zusatzlich Informationen uber die Anwendung als solche beinhaltet. Des 
weiteren beinhaltet das Dictionary den Satz von Instanzen, die Meta-lnformationen 
fur Klassen definieren. 

Durch das Meta-Anwendungs-Dictionary wird also eine Menge von Eigenschaften 
festgelegt, die fur jede Klasse im Server gelten. Somit ist eine Erweiterung bzw. 
Veranderung des Verhaltens des gesamten Systems 1 wahrend der Laufzeit mog- 
lich, ohne den bestehenden Code andern zu mussen. Diese Erweiterungen werden 
implementiert, indem sie von den Geschaftsklassen, die im Server aufgefuhrt wer- 
den, abgeleitet werden oder als neue Klassen hinzugefugt werden. Die neuen 
Klassen werden in den Server konfiguriert, indem die Meta-Anwendungs- 
Einrichtungen des Servers verwendet werden. Diese Unterklassen konnen die 
meisten der existierenden Methoden uberschreiben und haben daher die Moglich- 
keit, die bestehende Funktionalitat zu verandern oder zu erweitern. 

Fig. 5 zeigt eine schematische Darstellung der Entwicklung von den vorbekannten 
Systemen 14 zu einer ersten und einer zweiten Ausfuhrungsform des erfindungs- 
gemaften Abrechnungs- und Kundenvenwaltungssystems 1. Die in Fig. 5 vorge- 
nommene Einteilung der Systeme in drei logische Ebenen fur Prasentationslogik 
82, Anwendungslogik 80 und Datenbank 84 ist dabei lediglich als Hintergrund fur 
die bisher beschriebene Einteilung des erfindungsgema&en Abrechnungs- und 
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Kundenverwaltungssystems 1 in physikalische Ebenen anzusehen, von denen wie 
erwahnt bevorzugterweis mehr als drei existieren konnen. 

In den vorbekannten Systemen 14 bildeten Prasentationslogik 82, Anwendungslo- 
gik 80 und Datenbank 17 jeweils einen groBen Block mit entsprechenden Kommu- 
nikationsmoglichkeiten, die zu Fig. 1 bereits ausfuhrlich erlautert wurden. Im erfin- 
dungsgemaBen System 1 ist es nun nicht nur moglich, die Anwendungslogik 80 
entsprechend den angebotenen Dienstleistungen zu separieren, vielmehr ist es 
auch denkbar t dali die Datenbank 7 selbst in logisch getrennte Datenbankabschnit- 
te 12 aufgeteilt wird, anstelle einen grofcen monolytischen Block zu bilden und/oder 
daft mehrere voneinander getrennte Datenbanken 12 existieren. Jeder Datenban- 
kabschnitt und/oder jede getrennte Datenbank 12 ist dann genau fur eine Kompo- 
nente 5 zustandig, der sie Daten liefert und von der sie Daten abspeichert. 

Durch das vorliegende Abrechnungs- und Kundenverwaltungssystem 1 ist es mog- 
lich, weitere Anwendungsserver entsprechend bereits vorliegenden Servern zu re- 
produzieren und parallel zu diesen einzusetzen. Dadurch ist das Abrechnungs- und 
Kundenverwaltungssystem 1 auch fur Systemnutzer mit einigen Millionen abzu- 
rechnender Kunden und einer hohen Anzahl an Transaktionen geeignet. 

AuBerdem stellt das System 1 Mechanismen zur Verfugung, die ein uber die Kom- 
ponenten 5 verteiltes Transaktions- und Speichermanagement ermoglichen. 

Das oben dargestellte bevorzugte Modell des Abrechnungs- und Kundenverwal- 
tungssystems 1 ist lediglich als bevorzugte Ausfuhrungsform aufzufassen, denkbar 
sind jedoch viele Abwandlungen von dieser speziellen Ausfuhrungsform. So ist bei- 
spielsweise die Anzahl der Schichten und Ebenen nicht exakt durch die in obigem 
Beispiel beschriebene Anzahl definiert, sondern kann beliebig nach oben oder un- 
ten variiert werden, solange die Unterteilung in mindestens zwei Schichten und 
mindestens zwei Ebenen beibehalten wird. Das System 1 la&t sich auch beliebig 
auf dunne oder dicke Clients anwenden. Die genaue Aufteilung in Komponenten 5, 
die zu Fig. 1 erlautert wurde, ist ebenso lediglich als Beispiel aufzufassen. Dem- 
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nach konnen auch andere Dienstleistungen des Abrechnungs- und Kundenverwal- 
tungssektors zu einer entsprechenden Komponente 5 zusarnmengefaftt werden, 
solange die allgemeinen Kriterien fur eine Komponente 5 erfullt werden. Auch die 
Verwendung von Java, CORBA und TopLink ist lediglich eine Frage des aktuellen 
Marktangebots; genauso ist es denkbar, andere Produkte mit ahnlichen Eigen- 
schaften fur die vorliegenden Zwecke einzusetzen. 

Besonders sei darauf hingewiesen, dali das Abrechnungs- und Kundenverwal- 
tungssystem 1 nicht auf den Einsatz im Telekommunikationsbereich beschrankt ist. 
Vielmehr ist es durchaus moglich, das System 1 in der gesamten Verbraucherin- 
dustrie (Strom, Wasser, Gas, Internet etc.) einzusetzen bzw. Teile des Systems 1 
zur reinen Kundenverwaltung in Betrieben zu verwenden. 
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EPO - Munich 
24 

Pat ntanspriich 3 I MaTZ 2000 

1. Abrechnungs- und Kundenverwaltungssystem (1), insbesondere fur Kom- 
munikationsdienste, mit 

mindestens einer Datenbank (7), in der Daten gespeichert und abgerufen 
werden konnen, und die bevorzugterweise als Server ausgebildet ist, 

einer Mehrzahl von Clients, die mit der mindestens einen Datenbank (7) 
kommunizieren, und/oder mindestens einem Anwendungsserver mit zuge- 
horigen Clients, der mit der mindestens einen Datenbank (7) kommuniziert, 
und 

einem entsprechenden Framework (10), 

wobei dem Benutzer des Systems (1) entsprechende Dienstleistun- 
gen gemaR den jeweils gewunschten Abrechnungs- oder Kunden- 
verwaltungsvorgangen zur Nutzung offen stehen, 

dadurch gekennzeichnet, daft 

das System (1) eine verteilte Komponentenarchitektur aufweist, in der ent- 
sprechend den angebotenen Dienstleistungen Komponenten (5) ausgebildet 
sind, die uber Schnittstellen direkt miteinander kommunizieren konnen. 

2. Abrechnungs- und Kundenverwaltungssystem (1) nach Anspruch 1, dadurch 
gekennzeichnet, dafc das System (1) in mindestens zwei hierarchisch ange- 
ordnete Schichten (Layers) zunehmenden Abstraktionsgrades unterteilt ist, 
wobei die jeweils nachstuntere die uber ihr liegende Schicht nach unten iso- 
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liert, so daft Implementierungsdetails der unterliegenden Schichten den da- 
rtiberliegenden Schichten verborgen bleiben. 

3. Abrechnungs- und Kundenverwaltungssystem (1) nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, da& das System (1) in mindestens zwei hierar- 
chisch angeordnete Ebenen (Tiers) entsprechend den technischen Aufga- 
ben unterteilt ist, wobei die Elemente aller Ebenen zusammen die Aufgaben 
von der Speicherung bis zur Presentation der Daten vollstandig erfullen. 

4. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 3, dadurch gekennzeichnet, dali das System (1) eine unterste Ba- 
sisschicht (Base Layer) (40) aufweist, die fundamentals Systemverhalten 
beinhaltet. 

5. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 4, dadurch gekennzeichnet, dafl das System (1) eine Qber der 
Basisschicht (40) angeordnete allgemeine Schicht (Common Layer) (42) 
aufweist, die Abstraktionen von Klassen der Basisschicht (40) und Klassen 
beinhaltet, die allgemeine Einrichtungen fur alle Schichten und Ebenen lie- 
fern. 

6. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 5, dadurch gekennzeichnet, dad das System (1) eine uber der all- 
gemeinen Schicht (42) angeordnete technische Unterstutzungsschicht 
(Technical Services Layer) (44) aufweist, die software-tech nische Dienste 
anbietet. 

7. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 6, dadurch gekennzeichnet, daB das System (1) eine uber der 
technischen Unterstutzungsschicht (44) angeordnete Anwendungsschicht 
(Application Layer) (46) aufweist, die die Dienste der technischen Unterstut- 
zungsschicht (44) zu einer abstrakten Anwendung zusammenfaBt sowie 
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Mechanismen zur Beschreibung der Elemente der Domainebene (58) auf 
einer Meta-Ebene erlaubt. 

8. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 7, dadurch gekennzeichnet, daB das System (1) eine uber der 
Anwendungsschicht (46) angeordnete Geschaftsschicht (Business Layer) 
(50) aufweist, die die domainspezifischen Klassen fur jede Komponente (5) 
beinhaltet. 

9. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 8, dadurch gekennzeichnet, daB das System (1) eine Prasentati- 
onsebene (Presentation Tier) (52) aufweist, die die Presentation der Daten 
und Funktionen der Anwendung fur den Systemnutzer implementiert 

10. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 9, dadurch gekennzeichnet, daB das System (1) eine Anwen- 
dungsebene (Application Tier) (54) aufweist, die Klassen sowie Schnittstel- 
len beinhaltet, die die Anwendung reprasentieren. 

11. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 10, dadurch gekennzeichnet, daB das System (1) eine Meta- 
Anwendungsebene (Meta-Application Tier) (56) aufweist, in der Klassen 
beinhaltet sind, die einer Anwendung Mittel liefern, um sich selbst zu be- 
schreiben. 

12. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 11, dadurch gekennzeichnet, dali das System (1) eine Domaine- 
bene (Domain Tier) (58) aufweist, die die Geschaftsobjektklassen (business 
object classes) einer spezifischen Anwendungsdomain beinhalten. 

13. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Ansprii- 
che 1 bis 12, dadurch gekennzeichnet, daB das System (1) eine Persi- 
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stenzebene (Persistence Tier) (60) aufweist, die zum einen eine Abbildung 
des Klassenmodells der Domainebene (58) auf das Datenmodell der min- 
destens einen Datenbank (7) darstellt und zum anderen Mechanismen zur 
transaktionsgesicherten Manipulation der Daten in der mindestens einen 
Datenbank (7) unterstutzt. 

14. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 13, dadurch gekennzeichnet, dafi das System (1) ein Meta- 
Anwendungs-Dictionary (Meta-Application Dictionary) aufweist, das Infor- 
mationen uber eine Komponente (5), ihre Klassen und die Attribute in den 
Klassen beinhaltet und die dynamische Konfiguration von Anwendungsin- 
formationen und Verarbeitung auf einem Meta-Level erlaubt. 

15. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 14, dadurch gekennzeichnet, daB das System (1) Einrichtungen 
(68) aufweist, die das Schnittstellenmodell des Servers auf Clientseite (70) 
zur Verfugung stellen und damit die eingesetzte Kommunikationstechnologie 
vor einem Client-Entwickler verbergen. 

16. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Ansprii- 
che 1 bis 15, dadurch gekennzeichnet, dafi das System (1) definierte 
Schnittstellen sowie Mechanismen zur Anfrageverteilung anbietet, so dafl 
mehrere gleichartige Anwendungsserver dem System (1) hinzugefugt wer- 
den konnen. 

17. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 16, dadurch gekennzeichnet, daB das System (1) die Moglichkeit 
bietet, Komponenten (5) auszutauschen oder hinzuzufugen. 

18. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 17, dadurch gekennzeichnet, dali Klassen erweitert bzw. neue 
Klassen hinzugefugt werden konnen, um eine Komponente wahrend der 
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Ausfuhrung unter Verwendung von Meta-Anwendungs-Einrichtungen zu 
verandern. 

19. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 18, dadurch gekennzeichnet, daS die Datenbank (7) als eine Viel- 
zahl unabhangiger Datenbankabschnitte (12) ausgebildet ist und/oder meh- 
rere unabhangige Datenbanken (12) existieren, wobei die unabhangigen 
Datenbankabschnitte und/oder unabhangigen Datenbanken (12) jeweils mit 
nur einer Komponente (5) kommunizieren. 

20. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 19, dadurch gekennzeichnet, dali das System (1) Mechahismen 
zur Verfugung stellt, die ein uber Komponenten (5) verteiltes Transaktions- 
und Speichermanagement ermoglichen. 
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Zusammenfassung 3 I. M3n 2000 



Abrechnungs- und Kundenverwaltungssystem 



Die vorliegende Erfindung betrifft ein Abrechnungs- und Kundenverwaltungssystem 
(1), insbesondere fur Kommunikationsdienste, mit mindestens einer Datenbank (7), 
in der Daten gespeichert und abgerufen werden konnen und die bevorzugterweise 
als Server ausgebildet ist. Das System (1) weist eine Mehrzahl von Clients auf, die 
mit der Datenbank (7) kommunizieren, und/oder mindestens einen Anwendungs- 
server mit zugehorigen Clients, der mit der Datenbank (7) kommuniziert, sowie ein 
entsprechendes Framework (10). Dem Benutzer des Systems (1) werden entspre- 
chende Dienstleistungen gemaB den jeweils gewunschten Abrechnungs- und Kun- 
denverwaltungsvorgangen zur Nutzung angeboten. Das System (1) ist dadurch 
gekennzeichnet, dall es eine verteilte Komponentenarchitektur aufweist, in der ent- 
sprechend den angebotenen Dienstleistungen Komponenten (5) ausgebildet sind, 
die uber Schnittstellen direkt miteinander kommunizieren konnen. 



Fig. 2 
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